Time-Based Detection Strategies

ConceptAnalysisObject) . Here is an issue (specific to Smalltalk because all data are private and we have no ’protected’ keyword) about who use this data: foreign classes or children. If the data is used by children is less painful comparing with the other case. We could find some false negatives among the suspects which were not detected when using the most constrained thresholds but whose DataClass property span over their entire lifetime. As DataClass flaws are the descendants of classic structures from C language, used only as a way to organize the data, they tend to remain unchanged for their entire life. Furthermore, the typical DataClasses proved to be very stable (thus the majority of DataClass suspects are IdleClass). This is quite normal as by definition a DataClass is a light and dumb class which has almost no responsibility. The complexity of a suspect is given in the current definition using the WOC metric. This metric it assumes that complexity is given by the size of the non-trivial interface of the class. A recurrent problem while identifying the DataClasses is represented by UI classes. In their case there is a lot of inherited functionality provided by the MVC framework. All that children have to supply is the data required for UI aspects (which is usually quite a lot of data) and some basic functionality to maintain the UI consistent with changes fired up by the user. Out of the presented results we can see that the time adds a significant amount of information to the classic DataClass detection strategies. The evolution is therefore meaningful to be incorporated into a new way of detecting the DataClass suspects. This way we obtain the TimedDataClass and StableDataClass detection strategies. The results obtained from applying them with the most relaxed set of thresholds for the classic DataClass was summarized in Table 5.10. The definitions of the newly defined detection strategies, as given in SOD [Mar02], are: TimedDataClass:= (((WOC, BottomValues(33%)) and (WOC, LowerThan(0.50))) and ((NOPA, HigherThan(5)) or (NOAM, HigherThan(5))) HistoryToVersionMatrixCollection (ApparitionFreqCount, HigherThan(95%))) StableDataClass:= (((WOC, BottomValues(33%)) and (WOC, LowerThan(0.50))) and ((NOPA, HigherThan(5)) or (NOAM, HigherThan(5))) HistoryToLastVersionAdapter (LOCStability, HigherThan(90%)) 64 CHAPTER 5. VALIDATION Case Study Detection Strategy No. of No. of No. of No. of Name suspects flaws False Pos False Neg Classifier DataClass 9 3 6 0 (Experiment 2) TimedDataClass 9 3 6 0 StableDataClass 4 2 2 1 Conan DataClass 8 3 5 0 (Experiment 3) TimedDataClass 5 2 3 1 StableDataClass 5 3 2 0 Jun DataClass 60 ? ? ? (Experiment 3) TimedDataClass 51 ? ? ? StableDataClass 38 ? ? ? Figure 5.10: Time Based DataClass conclusions Conclusions: From Table 5.10 we can observe that using StableDataClass reduces a lot the number of suspects. However StableDataClass introduces more false negatives than TimedDataClass. The first is very vulnerable to minor modifications (e.g. initializations) while the later is vulnerable to refactorings (i.e. it doesn’t catch the evolutionary DataClass flaws which are the results of some refactorings). The fact that more than 90% of the DataClasses have this property from their birth (i.e. that the number of the EvolutionaryDataClass see Section 5.3.6 classes is small) is at first sight somehow surprising as we would expect that more DataClasses are the result of some refactorings. However, if we consider that the Object-Oriented technology offers support for the data centric decomposition of a domain problem we find that the data abstractions identified at the design time, which correspond to the nouns found in the modeled domain, are very stable and thus the movement of the data between classes is less likely to happen. The massive functionality extraction from a class while the data remain on the same place is also quite unlikely to happen. We enumerate the major refactorings [Fow99] (i.e. we ignore those triggered by the usage of a multi-paradigm language e.g. Replace record with Data Class and most of those related to generalization (because it is arguable whether a class up in the hierarchy can be DataClass or not) e.g. Extract Superclass), which could lead to DataClass classes: Move method, Move field, Extract class, Pull Up Method. We will look at the rationale which drive these refactrings: • Move Method “I usually look through the methods on a class to find a method that seems to reference another object more than the object it lives on”. Moving methods triggers DataClasses only when they did not belong at all to the starting class thus at the design time there was a huge misunderstanding of the class’s purpose and this is quite unlikely to happen. • Move Field “I consider moving a field If I see more methods on another class using the field than the class itself.”[Fow99] From this description it is obvious that this refactoring ca not lead to DataClasses as the field is moved in the direction of functionality. 5.3. QUALITY REFINED THROUGH EVOLUTION 65 • Extract Class “Such a class is one with many methods and quite a lot of data. A class that is too big to understand easily.”[Fow99] The results of this refactoring is unlikely to be DataClass classes. • Pull Up Method “The easiest case of using Pull Up Method occurs when the methods have the same body, implying that there’s been a copy and paste”[Fow99]. This refactoring is usually a means to factorizing the behavior of two children into their superclass and thus also unlikely to produce DataClass classes. What we wanted to prove above was that in a decent object-oriented system it is indeed quite unlikely to obtain DataClass classes through refactoring and this confirms our empirical results. 5.3.3 GodClass Experiments In the following we will present the GodClass expression that we used for our experiments (the language used is SOD [Mar02]). This expression is modified beside the original one which was presented in Section 3.1.2. GodClasses := ((ATFD, TopValues(20%)) and (ATFD, HigherThan(4))) and ((WMC, HigherThan(20)) or ((TCC, LowerThan(0.33) and (NOA, HigherThan(3))))) Because of the large number of methods and the small number of attributes from a class (e.g. especially for meta-classes), the TCC (Tight Class Cohesion) metric is always very small. If the number of attributes for a class is 0 then TCC will be 0 (for the computation details of TCC please refer to Section B.1.6) and according to the above definition many classes will be reported as GodClass suspects. Conan Case Study A Short Characterization of Suspects • ConceptAnalysisConcept(****) a big class with many methods. • ConcetpAnalysisContext(****) a very big class. • InternalMSEClassBehavior(***) many of the methods are heavy even if their cyclomatic complexity is not very high. • MSEInvocationObject class(***) heavy weighted class. No class variables are declared so the class is only a collection of independent methods. 66 CHAPTER 5. VALIDATION GodClass Apparition Suspects Freq Experiment 1 ConanApp 1/3 ConceptAnalysisConcept 1 ConceptAnalysisContext 1 Experiment 2 ConanApp 1 ConanNavigatorBrowser 1 ConceptAnalysisConcept 1 ConceptAnalysisContext 1 MSEInvocationObject class 7/8 InternalMSEClassBehavior 5/17 Experiment 1 GodClasses := ((ATFD, TopValues(10%)) and (ATFD, HigherThan(30))) and ((WMC, HigherThan(50)) or ((TCC, LowerThan(0.15) and (NOA, HigherThan(10))))) Experiment 2 GodClasses := ((ATFD, TopValues(10%)) and (ATFD, HigherThan(20))) and ((WMC, HigherThan(30)) or ((TCC, LowerThan(0.15) and (NOA, HigherThan(10))))) Figure 5.11: Evolution of GodClass property in Conan case-study • ConanApp(***) a few heavy-weighted methods are present and a lot of light weighted methods. • ConanNavigatorBrowser(*) UI class. A lot of wrapper methods for instance variables which use late initialization. These conditionals increase the WMC by 30%. Comments on the found suspects We found two very big classes: ConceptAnalysisConcept and ConcetpAnalysisContext which after manual inspection proved to be big from their birth. However these two classes are not conforming to the general intuition that GodClass suspects are more a result of system’s evolution. On the other hand we found two classes (i.e. InternalMSEClassBehavior and ConanApp) which became GodClass suspects by evolution. These classes have different structures: ConanApp has NOM = 44 and WMC = 52, while InternalMSEClassBehavior has in NOM = 32 and WMC = 33 (both measurements were done in version 1.102). This anomaly (i.e. after manual inspection we found InternalMSEClassBehavior to be more GodClass suspect than 5.3. QUALITY REFINED THROUGH EVOLUTION 67 GodClass LOC NOM Suspects Instability Instability ConceptAnalysisContext 3/7 1/3 ConceptAnalysisConcept 3/7 2/7 InternalMSEClassBehavior 8/17 6/17 MSEInvocationObject class 1/8 1/8 ConanApp 7/9 7/9 ConanNavigatorBrowser 1/8 0 Figure 5.12: Stability of GodClass suspects in Conan case-study ConanApp) is due to the fact that the relevance of the cyclomatic complexity [McC76] decreases generally in object oriented languages and especially in Smalltalk. (see Section B.1.3). MSEInvocationObject class represents another kind of classes. It has only 19 methods (version 1.102) but the majority of them are quite complex. Without any instance variable, it acts as a bunch of methods put together, more like functions in procedural code. The stronger GodClass suspects proved to be as expected more instable than the others. Classifier Case Study A Short Characterization of Suspects • ClassifierDrawing(***) heavy-weighted class. Its ATFD metric has low value even if the WMC is very high. • AbstractGroupUI(**) a big UI class with lots of methods, many of them being wrappers for aspects variables. Part of the complexity is due to the late initialization. • GroupUI(*) UI class, not heavy-weighted. • AbstractOperation(*) not very heavy-weighted. Comments on the found suspects The most prominent GodClass suspect (i.e. ClassifierDrawing) got this feature during its lifetime. Again we have here two UI classes. One of them (i.e. AbstractGroupUI) wraps a very complex dialog. Due to the fact that this project is quite small the UI classes have a greater importance here. If we ignore the two graphical interface classes we can see the following: • ClassifierDrawing has a higher instability beside AbstractOperation which corresponds to the degree in which it is a GodClass flaw. When we used 68 CHAPTER 5. VALIDATION GodClass Apparition Suspects Freq Experiment 1 AbstractGroupUI 1 Experiment 2 AbstractGroupUI 1 AbstractOperation 1 ClassifierDrawing 5/17 GroupUI 5/8 Experiment 1 GodClasses := ((ATFD, TopValues(10%)) and (ATFD, HigherThan(30))) and ((WMC, HigherThan(50)) or ((TCC, LowerThan(0.15) and (NOA, HigherThan(10))))) Experiment 2 GodClasses := ((ATFD, TopValues(10%)) and (ATFD, HigherThan(20))) and ((WMC, HigherThan(30)) or ((TCC, LowerThan(0.15) and (NOA, HigherThan(10))))) Figure 5.13: Evolution of GodClass property in Classifier case-study GodClass LOC NOM Suspects Instability Instability ClassifierDrawing 10/17 5/17 AbstractGroupUI 16/17 11/17 GroupUI 3/4 3/8 AbstractOperation 4/17 3/17 Figure 5.14: Stability of GodClass suspects in Classifier case-study the more constrained thresholds we got ClassifierDrawing as a false negative but analyzing its instability we could compensate the noise when computing the McCabe’s cyclomatic complexity (Section B.1.3). • ClassifierDrawing was detected to be a pulsar which amplifies its instability. AbstractGroupUI and GroupUI were detected as supernovas. The manual inspection proved that both of this classes grew in the first part of their life due to the features added to the GUI.GroupUI and GroupUI were detected as supernovas. The manual inspection proved that both of this classes grew in the first part of their life due to the features added to the GUI. 5.3. QUALITY REFINED THROUGH EVOLUTION 69 Fraction of Apparition GodClasses Freq Experiment 1 5/14 = 36% > 95% 1/14 = 7% > 70% & < 95% 8/14 = 57% < 70% Experiment 2 11/20 = 55% > 95% 2/20 = 10% > 70% & < 95% 7/20 = 35% < 70% Experiment 3 20/37 = 54% > 95% 5/37 = 14% > 70% & < 95% 12/37 = 32% < 70% Experiment 1 GodClasses := ((ATFD, TopValues(5%)) and (ATFD, HigherThan(70))) and ((WMC, HigherThan(90)) or ((TCC, LowerThan(0.15) and (NOA, HigherThan(15))))) Experiment 2 GodClasses := ((ATFD, TopValues(10%)) and (ATFD, HigherThan(50))) and ((WMC, HigherThan(70)) or ((TCC, LowerThan(0.15) and (NOA, HigherThan(15))))) Experiment 3 GodClasses := ((ATFD, TopValues(10%)) and (ATFD, HigherThan(30))) and ((WMC, HigherThan(50)) or ((TCC, LowerThan(0.15) and (NOA, HigherThan(10))))) Figure 5.15: Evolution of GodClass property in Jun case-study